CT Test Results

    6 files    205 suites   2h 4m 50s ⏱️
2 122 tests 2 051 ✅ 71 💤 0 ❌
2 891 runs  2 796 ✅ 95 💤 0 ❌

Results for commit 9c412cb.

♻️ This comment has been updated with latest results.

To speed up review, make sure that you have read Contributing to Erlang/OTP and that all checks pass.

See the TESTING and DEVELOPMENT HowTo guides for details about how to run test locally.

Artifacts

• Complete CT logs (Download Logs)
• HTML Documentation (Download HTML Docs)
• Windows Installer

// Erlang/OTP Github Action Bot

From what I can tell only our github actions dependencies are scanned by this right now, is that correct? Will it in the future be able to use the information in the sbom created in the job you are adding this step to? or is this check only for github actions?

I think you are right @garazdawi
I have updated the PR to scan for vulnerabilities using OSV.

Summary

• CC++ works better in OSV providing a sha, and they do range analysis.
• Our vendor libraries should provide a versionInfo, and in the case of CC++ vendor libraries, we should provide the sha as well. If there is no sha, then we cannot do vulnerability scanning for this CC++ vendor library.
• If a vendor library belongs to an ecosystem, we write its ecosystem in the vendorInfo.
  OSV works better for standard ecosystems, such as npm, maven, hex, etc.

I have tested that it works by manually hand-picking previous commit that fixed a known vulnerability reported to on github repos.

Information sent

{
  "queries": [
    {
      "commit": "1a8db63788c34a50e39e273d39b7e1033208aea2",
      "package": { "name": "github.com/madler/zlib" }
    },
    {
      "commit": "a465fe71ab3d0e224b2b4bd0fac69ae68ab9239d",
      "package": { "name": "github.com/asmjit/asmjit" }
    },
    {
      "commit": "f8745da6ff1ad1e7bab384bd1f9d742439278e99",
      "package": { "name": "github.com/facebook/zstd" }
    },
    {
      "commit": "442029c6fa37f1b6f9203357de09672d5704077c",
      "package": { "name": "github.com/microsoft/STL" }
    },
    {
      "commit": "1264a946ba66eab320e927bfd2362e0c8580c42f",
      "package": { "name": "github.com/ulfjack/ryu" }
    },
    {
      "commit": "cdfb0923a66155ce97640fca68ae57b3a2972029",
      "package": { "name": "github.com/openssl/openssl" }
    },
    {
      "commit": "1e09555d6950bfcf83bd98fa597b0c6440d43c9c",
      "package": { "name": "github.com/PCRE2Project/pcre2" }
    },
    {
      "commit": "636dfadc70ce26f2473870570bfd9ec352806b1d",
      "package": { "name": "github.com/openssl/openssl" }
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "tablesorter"
      },
      "version": "2.32"
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "jquery"
      },
      "version": "3.7.1"
    },
    {
      "commit": "fd0f60daea24e9c62d372d774be9e32ce2b0849d",
      "package": { "name": "github.com/wxWidgets/wxWidgets" }
    }
  ]
}

Result

[OSV] There are existing vulnerabilities:
- github.com/madler/zlib: CVE-2023-45853
- github.com/openssl/openssl: CVE-2024-12797
- github.com/PCRE2Project/pcre2: OSV-2024-1237
- github.com/wxWidgets/wxWidgets: CVE-2024-58249

The vendor vulnerability scanning now fails because I changed the vendor.json sha to refer to existing CVEs, and this PR detects them (https://github.com/erlang/otp/actions/runs/14845728041/job/41679578778?pr=9790 for otp, and this for my fork https://github.com/kikofernandez/otp/actions/runs/14845971887/job/41680388662)

This pull request sets up GitHub code scanning for this repository. Once the scans have completed and the checks have passed, the analysis results for this pull request branch will appear on this overview. Once you merge this pull request, the 'Security' tab will show more code scanning analysis results (for example, for the default branch). Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results. For more information about GitHub code scanning, check out the documentation.

I have updated the scripts and this is the end result, using OSV for vulnerability scanning.

1. Perform vulnerability scanning per PR. If a CVE is found the PR fails that test
2. Perform vulnerability scanning as per scheduled and fan out per branch. If a CVE is found, create a SARIF file and upload to GH, such that GH Security contains those under Code Scanning on a per last three release basis. (we avoid duplicates via fingerprinting, and postpone the OpenVex integration for now)